Handle hardlinks with file-based app csc optimization #51135
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR fixes a bug in the file-based app CSC optimization when hardlinks are enabled in the build process. The issue occurred when both source (obj) and destination (bin) files are hardlinked, causing unnecessary copy operations that could fail or behave unexpectedly.
- Adds a check to compare file size and timestamp before copying compiled assemblies
- Skips the copy operation when files are already identical (due to hardlinking)
- Includes a test case to verify the hardlink scenario works correctly
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/Cli/dotnet/Commands/Run/CSharpCompilerCommand.cs | Implements size and timestamp comparison logic to avoid unnecessary file copies when hardlinks are present |
| test/dotnet.Tests/CommandTests/Run/RunFileTests.cs | Adds test case that enables hardlinks and verifies the optimization works correctly |
| var objFile = new FileInfo(parsedArgs.GetOutputFilePath(outputFileName)); | ||
| var binFile = new FileInfo(BuildResultFile); |
There was a problem hiding this comment.
Creating FileInfo objects here may cause unnecessary file system calls. Consider creating them only when needed inside the HaveMatchingSizeAndTimeStamp method, or check if the files exist first to avoid exceptions.
Copilot uses AI. Check for mistakes.
|
What was the unwanted behavior, which is being fixed by this PR? |
|
The |
Fixes a bug which I discovered while using file-based apps in roslyn repo with hardlinks in build opted-in (via
ROSLYNUSEHARDLINKSenv var).The
File.Copyresulted in "Access denied" exception. I was puzzled at first, but after some investigation discovered that's because the MSBuild task hardlinksobj/app.dllwithbin/app.dlland when we then try toFile.Copy("obj/app.dll", "bin/app.dll")it fails with that exception because it tries to write to a file which it has locked for reading (because both files are actually the same file via the hardlink).MSBuild's Copy task doesn't have this problem because it by default checks the files have the same size and timestamp and if so, the copy is skipped. I have implemented the same behavior to fix the issue.